1 




LeA 36,280 

IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



APPLICATION OF ) 

KARSTEN DIERKSEN ET AL ) 

SERIAL NUMBER: 10/689,163 ) 

FILED: OCTOBER 20, 2003 ) 

TITLE: METHOD AND COMPUTER SYSTEM FOR ) 

PROJECT PORTFOLIO MANAGEMENT ) 

CLAIM FOR PRIORITY UNDER 35 USC 119 



Commissioner for Patents 
P. O. Box 1450 
Alexandria, VA 22313-1450 

Sir: 

Applicants hereby claim foreign priority benefits under Title 35, United States Code, 
1 19, as stated on their previously submitted Declaration and Power of Attorney document. 
Applicants further submit the enclosed certified copies of German application 1 02 49 482.7, 
claiming foreign priority on the above-identified U.S. application. 

Respectfully submitted, 



Bayer MaterialScience LLC 
1 00 Bayer Road 

Pittsburgh, Pennsylvania 15205-9741 
(412) 777-3808 

FACSIMILE PHONE NUMBER: 
(412) 777-3902 
lo/FRANKS/jrf172 



By 




~7 James R. Franks 
Agent for Applicants 
Reg. No. 42,552 



I hereby certify that this correspondence is being deposited 
with the United States Postal Service as first class mail in an 
enveloped addressed to: Commissioner for Patents, 
Alexandria, VA 22313-1450 08/12/04 



Date 

nes R. Franks. Rea. No. 42.552 




Signature 

August 12, 2004 
Date 



BUNDESREPUBLIK DEUTSCHLAND 




Prioritatsbescheinigung uber die Einreichung 
einer Patentanmeldung 



Aktenzeichen: 



102 49 482.7 



Anmeldetag: 



24. Oktober 2002 



Anmelder/lnhaber: 
Bezeichnung: 



Bayer Aktiengesellschaft, Leverkusen/DE 

Verfahren und Computersystem zum Projekt- 
portfoliomanagement 



IPC: 



G 06 F 17/60 



Die angehefteten Stiicke sind eine richtige und genaue Wiedergabe der ur- 
sprungllehett Unterlagen dieser Patentanmeldung. 



A 9161 

03/00 
EDV-L 



Munchen, den 2. Oktober 2003 
Deutsches Patent- und Markenamt 
Der President 

Im Auftrag 




CERTIFIED COPY OF 

*!ORITY DOCUMENT BEST AVAILABLE COPY 



Le A 36 280 Sw/by/NT/V06.09.2002 



- 1 - 

Verfahren und Computersystem zum Projektportfoliomanagement 

Die Erfindung betrifft ein Verfahren zum Projektportfoliomanagement sowie ein ent- 
sprechendes Computersystem und Computerprogrammprodukt. 

Ein wesentlicher Bestandteil des Projektportfoliomanagements ist das Risikomanage- 
ment. Aus dem Stand der Technik ist eine Vielzahl von Risikoanalyse-Methoden 
bekannt, die sich aus qualitativen und/oder quantitativen Techniken zusammen- 
setzen. Mit diesen Methoden wird die Entscheidungsfindung unterstutzt, indem z.B. 
die Wahrscheinlichkeit von moglichen Szenarien ermittelt oder Vorschlage zur 
Priorisierung gegeben werden. 

Ubliche Risikoanalyse-Methoden basieren auf der Monte Carlo-Simulation, Ent- 
scheidungsbaumen (sogenannte ^Decision Trees") und Einflussdiagrammen (soge- 
nannten „Influence Diagrams"). 

Von der Firma Palisade sind verschiedene Risikoanalyse-Computerprogramme 
kommerziell erhaltlich. Durch das Programm @RISK 4.0 wird Microsoft Excel oder 
Lotus 1-2-3 ein Risikoanalysen- und Simulations-add-in hinzugefugt. @RISK 
verwendet die Monte Carlo-Simulation, wobei im Kalkulationstabellen-Modell 
unbestimmte Werte durch @RJSK-Funktionen ersetzt werden, urn einen Bereich von 
moglichen Werten darzustellen. Auf diese Weise erhalt man eine Verteilung 
moglicher Ergebnisse sowie die entsprechenden Eintrittswahrscheinlichkeiten. Diese 
Ergebnisse werden grafisch aufbereitet ausgegeben, zum Beispiel in Form von 
Histogrammen, Summenkurven oder Flachen- und Liniendiagrammen. 

Das Computerprogramm „@RISK 4 Project" von Palisade beinhaltet zusatzliche 
Funktionen fur die Projektplanung. Dadurch konnen zusatzliche erweiterte Analysen 
ausgefuhrt werden, namlich eine Empfmdlichkeitsanalyse, Szenario-Analyse und 
kritische Indices. Mit Hilfe der Empfindlichkeitsanalyse wird festgestellt, welche 
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Eingabeverteilungen die grolite Auswirkung auf die Ausgaben haben. Die Ergebnisse 
konnen dann in einem leicht auszuwertenden Tornado-Diagramm dargestellt werden. 

Die Szenario-Analyse identifiziert dagegen die Eingabenkombinationen, die zu den 
Ausgabezielwerten fuhren. Durch kritische Indizes kann festgestellt werden, wenn 
eine Aufgabe wahrend der Simulation kritische Dimensionen annimmt. Bei 
kritischen Tasks handelt es sich dagegen um Aufgaben, fur die sich eine kritische 
Projektion ergibt, das heifit, durch die die Gesamtdauer des Projekts festgestellt 
werden kann. Alle kritischen Indizes werden automatisch fur samtliche Aufgaben als 
zeitliche Prozentwerte protokolliert, um in einem Projekt die kritischen Aufgaben zu 
identifizieren. 

Ein weiteres Beispiel fur Programme fur die Risikoanalyse und Entscheidungs- 
software ist " Adele" vom Dresdner Institut fur Entscheidungsanalysen. 

Ein gemeinsamer Nachteil vorbekannter Computerprogramme fur die Risikoanalyse 
ist, dass die Datenbasis fur die Durchfuhrung der Analyse nicht effizient zur Ver- 
fugung gestellt werden kann. Dies trifft insbesondere auf verteilte Projekte zu, die 
verschiedene Instanzen und Lokationen in einem Unternehmen involvieren. Eine 
weitere Schwierigkeit ist die Pflege der Datenbasis, um diese an den aktuellen Status 
eines Projekts anzupassen. 

Der Erfmdung liegt daher die Aufgabe zu Grunde ein verbessertes Verfahren zur 
Risikoanalyse und Management von Projektportfolien zu schaffen sowie ein ent- 
sprechendes verbessertes Computersystem und Computerprogrammprodukt. 

Die Erfindung ermoglicht es die verschiedenen Mitarbeiter eines Unternehmens, die 
in einem Projekt involviert sind, in die Datenerhebung fur die Risikoanalyse 
einzubinden. Fiir die funktionsbereichsspezifische Datenerhebung in dem Unter- 
nehmen werden Bereichschecklisten verwendet, die Eingabefelder zur Eingabe von 
Daten fur die Risikoanalyse aufweisen. Dabei wird fiir jeden in das Projekt 
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involvierten Funktions-Bereich des Unternehmens eine spezifische Bereichscheck- 
liste mit Eingabefeldern fur Daten, die von dem betreffenden Funktions-Bereich 
abgefragt werden sollen, verwendet Aus den so erhobenen Daten werden 
Risikoanalysen auf Projektebene erstellt. In einem weiteren Schritt wird daraus eine 
5 Risikoanalyse des gesamten Projektportfolios erstellt. 

Beispielsweise gibt es spezifische Bereichslisten fur „Forschung und Entwicklung", 
„regionales/strategisches Marketing", „Produktion", „Patentrecht und Lizenzen" und 
„Okologie" fur ein Projekt zur Entwicklung und Markteinfuhrung eines neuen 
10 chemischen Produkts durch ein Unternehmen der chemischen Industrie. 

'v 

Nachdem die erforderlichen Daten in samtliche der Bereichschecklisten eingegeben 
und in der hierarchischen Datenbank gespeichert worden sind, werden die Daten aus 
der hierarchischen Datenbank in eine relationale Datenbank exportiert. Dies ist von 
15 besonderem Vorteil, da sich eine hierarchische Datenbank besonders gut fur das 

raumlich verteilte Zusammentragen von Daten eignet. Eine solche Datenbank lasst 
sich vorzugsweise mit Lotus Notes realisieren; in diesem Fall handelt es sich bei den 
Bereichschecklisten urn Lotus Notes Dokumente. 

20 Das Lotus Notes Datenbank-System folgt einer flachen, hierarchischen Struktur. Ein 
Lotus Notes Dokument ist dabei eine autonome Einheit und enthalt Informationen 
iiber die Datenstruktur als auch iiber die Daten selbst. Die Dokumente in einer Lotus 
Notes Datenbank konnen also vollkommen verschiedene Strukturen aufweisen, da 
sie nicht an Tabellen geknupft sind. Ein weiterer Vorteil von Lotus Notes ist das 

25 Konzept der Replikation, welches eine raumlich verteilte Arbeitsweise erleichtert. 

Ein Nachteil einer hierarchischen Datenbank wie Lotus Notes ist jedoch, dass durch 
die flexible Struktur der Dokumente ein Einsatz von Abfragesprachen wie SQL nicht 
moglich ist. Dieser Nachteil wird erfindungsgemaB dadurch behoben, dass die Daten 
30 aus der hierarchischen Datenbank in eine relationale Datenbank exportiert werden, 
urn die fur die Risikoanalyse erforderlichen Berechnungen und statistischen Aus- 
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wertungen aufgrund der zuvor erhobenen Daten durchzufuhren. Dies kann dann mit 
einer grofien Verarbeitungsgeschwindigkeit erfolgen, da der Zugriff auf die in der 
relationalen Datenbank gespeicherten Daten effizient und schnell ist. 

Nach einer weiteren bevorzugten Ausfuhrungsform der Erfindung haben die Be- 
reichschecklisten einen initialen ersten Status und einen zweiten Status: 

Alle neu erstellen Bereichschecklisten befinden sich zu Beginn im Status „Entwurf \ 
Der Wechsel des Dokumentenstatus kann in einem Bearbeitungsmodus durch 
„Anklicken" der Aktionsschaltflache „Dokument vollstandig" durchgefuhrt werden. 
Als Voraussetzung hierfur sind jedoch zunachst alle Pflicht-Eingabefelder mit Daten 
zu fiillen, da das Dokument ansonsten nicht gespeichert werden kann. Die Pflicht- 
Eingabefelder sind vorzugsweise farblich markiert. Die Daten der Pflichtfelder gehen 
in die Risikoanalyse ein ? die dariiber-hinaus erhobenen Daten stellen weitere 
Informationen zum Projektumfeld bereit, die einer mathematischen Behandlung nicht 
oder nur sehr schwer zuganglich sind. 

Nach einer weiteren bevorzugten Ausfuhrungsform der Erfindung wird eine Master- 
checkliste erzeugt. Die Mastercheckliste ist eine den Bereichschecklisten 
ubergeordnete Instanz. Die Mastercheckliste hat den initialen Status „In Arbeit" 
sowie den weiteren Status „Komplett". Der Zustand „In Arbeit" ist solange gultig, 
wie zumindest eine der Bereichschecklisten noch im Zustand „Entwurf 6 ist. Damit 
die Mastercheckliste den Status „Komplett" erhalt, mussen alle der Mastercheckliste 
zugeordneten Bereichschecklisten den Dokumentenstatus „Dokument vollstandig" 
enthalten. Der Status der Mastercheckliste lasst sich uber die Aktionsschaltflachen 
auf dem Masterchecklisten-Dokument „Checklisten komplett" und „Checkliste in 
Arbeit setzen" verandern. 

Nachdem die Mastercheckliste den Status „Komplett" angenommen hat, ist eine 
weitere Bearbeitung von Bereichschecklisten nur moglich, wenn zunachst der Check- 
listen-Status der Mastercheckliste von „Komplett" auf „In Arbeit" zunickgesetzt wird 
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und im Anschluss daran, die zu bearbeitenden Bereichschecklisten in den 
Entwurfsstatus „Entwurf ' zuruckgesetzt werden. 

Nach einer weiteren bevorzugten Ausfuhrungsform der Erfindung werden die mit 
5 Hilfe der Checklisten eingegebenen Daten in eine relationale Datenbank, wie zum 
Beispiel eine Oracle Datenbank, exportiert. Dies kann periodisch innerhalb vorge- 
gebener zeitlicher Abstande erfolgen oder auch auf Anforderung eines Nutzers. 
Basierend auf den exportierten Projektdaten wird dann mit Hilfe der relationalen 
Datenbank eine Risikoanalyse durchgefuhrt. Vorzugsweise werden dabei ein oder 
^JJr 10 mehrere vorgegebene Risikoanalyse-Routinen abgearbeitet, die in ebenfalls vorge- 
gebenen grafischen Darstellungen ausgegeben werden . 

Von besonderem Vorteil ist hierbei, dass erfmdungsgemaB eine hierarchische Daten- 
bank fur die verteilte Erfassung und die Steuerung des Workflows fur die Daten- 
15 erfassung verwendet wird, wahrend die eigentliche Risikoanalyse in einer 
relationalen Datenbank durchgefuhrt wird. Auf diese Art und Weise konnen die fur 
die Risikoanalyse erforderlichen Projektdaten effizient, zeitnah und mit geringen 
Transaktionskosten erhoben werden, da sich die hierarchische Datenbank auf die 
Organisation des Unternehmens anpassen lasst. Andererseits werden die fur die 
20 Risikoanalyse erforderlichen Berechnungen und Auswertungen mit einer hohen 
J ^ Verarbeitungsgeschwindigkeit durchgefuhrt, da hierfur auf eine relationale Daten- 

bank, wie zum Beispiel Oracle, zugegriffen wird. 

Ein weiterer Vorteil des erfindungsgemaBen Verfahrens und des erfindungsgemaBen 
25 Computerprogrammes ist, das grundsatzlich alle Projekte, die in einer Firma oder 
einem Untemehmensbereich durchgefuhrt oder genehmigt werden sollen mit ihren 
Basisdaten wie z.B. Projektleitung, Mitarbeiter, Budget oder Zeitskala, erfasst 
werden. Von Fall zu Fall konnen diese Projekte dann einer Risikoanalyse zugefuhrt 
werden. Kriterien dafur konnen z. B: Budget, Laufzeit oder strategische Bedeutung 
30 sein. Nur fiir diese Projekt ist dann eine weitere Datenerhebung erforderlich. 
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Noch ein weiterer Vorteil des erflndungsgemafien Verfahrens und des erfindungs- 
gemaBen Computerpro grammes ist, die Moglichkeit auf Grund der fur alle Projekte 
die in einer Firma oder in einem Unternehmensbereich abgewickelt werden, erfassten 
Basisdaten, eine stundengenaue Aufwandserfassung fur die Mitarbeiter und fur die 
Projekte und damit fur das Projektportfolio durchzufuhren. 

Im weiteren werden bevorzugte Ausfuhrungsformen der Erfindung mit Bezugnahme 
auf die Zeichnungen naher erlautert Es zeigen: 

Figur 1 ein Flussdiagramm einer Ausfiihrungsform eines erfindungsge- 

mafien Verfahrens zur Risikoanalyse, 

Figur 2 ein Flussdiagramm fur die Risikoanalyse eines Einzelprojekts, 

Figur 3 ein Flussdiagramm fur die Risikoanalyse eines Projektportfolios, 

Figur 4 ein Blockdiagramm eines erfindungsgemaBen Computersy stems. 

In dem Schritt 100 erfolgt das Anlegen eines Projektes. Die Eingabe der Basisdaten 
erfolgt im Schritt 102. Diese Schritte werden fur alle Projekte einer Firma oder eines 
Unternehmensbereiches durchgefuhrt. Hierbei werden die Mitarbeiter, die die 
Projektarbeit leisten, erfasst. 

Im Schritt 104 werden die Basisdaten auf Vollstandigkeit und Aktualitat gepruft. 

Im Schritt 106 wird gepruft, ob fur das Projekt eine Risikoanalyse erstellt werden 
soli. Wenn nicht endet der Workflow hier. Es werden nur die Basisdaten vorgehalten 
und turnusmaBig aktualisiert (Schritt 104). Wenn eine Risikoanalyse erstellt werden 
soli, wird in dem Schritt 108 das Projektstammblatt erzeugt. Pro Projekt gibt es ein 
Projektstammblatt. Im Projektstammblatt werden die Projektteammitglieder 
festgelegt 
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Im Schritt 1 10 werden die Daten auf Vollstandigkeit gepruft. 

Lm Schritt 112 wird die Mastercheckliste erzeugt. Deren initialer Status ist "In 
Arbeit". In der Mastercheckliste werden die Verantwortlichen fur die einzelnen 
Bereichschecklisten aus der Liste der Projektteammitglieder ausgewahlt und ge- 
speichert. Es gibt eine Mastercheckliste fur jedes Teilprojekt innerhalb eines Pro- 
jektes. In der Mastercheckliste werden Abhangigkeiten zwischen Teilprojekten 
defmiert. 

Im Schritt 114 werden die Daten auf Vollstandigkeit gepruft. 

Danach werden in dem Schritt 116 die Bereichschecklisten erzeugt. Diese haben den 
initialen Status „Entwurf \ Jede der Bereichschecklisten ist spezifisch fur eine in das 
Projekt involvierte funktionale Einheit des Unternehmens, wie zum Beispiel 
„Forschung und Entwicklung", „regionales/strategisches Marketing", „Produktion", 
„Patentrecht und Lizenzen" und „Okologie'\ 

Eine Bereichscheckliste beinhaltet Eingabefelder zur Eingabe von Daten, die spezi- 
fisch fur die von der betreffenden Bereichscheckliste angesprochene funktionelle 
Unternehmenseinheit sind. 

Im Schritt 118 wird gepruft, ob die Daten einer Bereichscheckliste vollstandig und 
aktuell sind. Ist dies der Fall kann der Status der Bereichscheckliste auf "Vollstandig" 
gesetzt werden. 

Im Schritt 120 wird gepruft, ob der Status aller Bereichschecklisten auf "Vollstandig" 
gesetzt ist. Ist das der Fall, kann der Status der Mastercheckliste auf "komplett" 
gesetzt werden (Schritt 122). Eine weitere Bearbeitung der Bereichschecklisten ist 
dann nicht mehr moglich. 



Le A 36 280 



-8 - 

Die verschiedenen Zustande der Bereichschecklisten und der Mastercheckliste 
konnen liber Aktionsschaltflachen der betreffenden Checklisten verandert werden: 

Mastercheckliste 

„Checklisten komplett" 

Diese Schaltflache ist nur sichtbar, wenn sich die Mastercheckliste im Dokumenten- 
status „In Arbeit" befindet und zum Bearbeiten geoffnet ist. Der Checklistenstatus 
der Mastercheckliste wird hierbei von „In Arbeit" auf „Komplett" gesetzt. 
Voraussetzung hierfur ist jedoch, dass sich alle Bereichschecklisten im Dokumenten- 
status „Dokument Vollstandig" befinden. 

"Checklisten in Arbeit setzen" 

Diese Schaltflache ist nur sichtbar, wenn sich die Mastercheckliste im Dokumen- 
tenstatus "Komplett" befindet und zum Bearbeiten geoffnet ist. Der Checklistenstatus 
der Mastercheckliste wird hierbei von „Komplett" auf „In Arbeit" gesetzt. 

B er eichs checklis ten 

„Dokument vollstandig" 

Der Dokumentenstatus wird von „Entwurf * auf „ Vollstandig" gesetzt, 

Diese Schaltflache wird nur im Bearbeitungsmodus und im Dokumentenstatus 

„Entwurf 6 einer Bereichscheckliste angezeigt. 

..Entwurfstatus" 

Der Dokumentenstatus wird von „Vollstandig" auf „Entwurf ' zuriickgesetzt. Befin- 
det sich die Mastercheckliste bereits im Status „ Vollstandig", so ist hier das Zu- 
riicksetzen in den Entwurfsstatus nicht moglich. Die Schaltflache wird im Lese- als 
auch im Bearbeitungsmodus angezeigt, wenn sich das Dokument im Status Voll- 
standig" befindet. 
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Fiir den Fall, class ein Bearbeiter einer Bereichscheckliste doch eine Bearbeitung der 
Eingaben in die Bereichscheckliste, fur die er verantwortlich ist, fur erforderlich halt, 
ist der Schritt 124 vorgesehen. Wenn dort vom Verantwortlichen fur die Master- 
checkliste entschieden wird, dass eine weitere Bearbeitung notig ist, so wird in dem 
Schritt 126 die Mastercheckliste in den Status „In Arbeit" zuriickgesetzt. In dem 
Schritt 128 wird dann die zu andernde Bereichscheckliste in den Status „Entwurf" 
zuriickgesetzt, so dass eine Bearbeitung der Dateneingaben erfolgen kann. Danach 
wird wiederum der Schritt 118 durchgefuhrt und der Schritt 120, urn die 
Mastercheckliste in dem Schritt 122 gegebenenfalls wieder auf den Status 
„Komplett" zu setzen. 

Wenn keine weitere Bearbeitung mehr notig ist (Schritt 124) erfolgt in dem Schritt 
130 ein Export der eingegebenen Daten in eine relationale Datenbank. Dazu ist auf 
der Mastercheckliste eine Aktionsschaltflache „Datenexport" vorhanden. Diese 
bewirkt einen Datenexport in eine relationale Datenbank, wie zum Beispiel Oracle. 

Beim Datenexport ist zwischen vier verschiedenen Varianten zu unterscheiden: 

(1) Indirekter Export einer aktuellen Version eines Teilprojekts auf Anforderung 
(Version R) 

(2) Export einer aktuellen Version eines Teilprojekts (Version A) 

(3) Export einer offiziellen Version eines Projekts (V ersion O) 

(4) Export von offiziellen Versionen aller Projekte (Version (OA) 

Bei der Variante (1) werden die Daten beim nachsten Lauf des sogenannten 
Exportagenten in die relationale Datenbank exportiert. Der Exportagent kann z.B. 
einmal pro Stunde laufen. Bei der Variante (2) werden alle aktuellen Teilprojekte 
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einmal innerhalb von 24 Stunden in die relationale Datenbank exportiert, dies kann 
z.B. einmal pro Nacht geschehen. 

Bei Variante (3) erfolgt der Export einer offiziellen Version eines Projektes in die 
relationale Datenbank auf Knopfdruck. Bei der Variante (4) werden alle offiziellen 
Versionen aller Projekte auf Knopfdruck in die relationale Datenbank exportiert. 

Ein gestarteter Export protokolliert Eckdaten und verschickt am Ende eine Mail an 
eine Mail-In-Datenbank, in der evtl. vorliegende Fehler beim Ablauf der Routine 
nachgelesen werden konnen. Von alien offiziellen Projekten, die in die relationale 
Datenbank exportiert wurden, wird automatisch eine Kopie „eingefroren" und die 
Versionsnummer urn 1 erhdht. 

Nach dem Export der Daten in die relationale Datenbank erfolgt die Risikoanalyse. 
Hierzu wird in dem Schritt 200 auf die in der relationalen Datenbank gespeicherten 
Projektdaten zugegriffen. Basierend auf den Projektdaten werden in dem Schritt 202 
eine oder mehrere vorgegebene Risikoanalysen durchgefuhrt. Die Ergebnisse werden 
in dem Schritt 204 grafisch ausgegeben. 

Altemativ kann auch eine Risikoanalyse fur ein Projektportfolio durchgefuhrt 
werden. Dies wird in der Figur 3 veranschaulicht. 

In dem Schritt 300 erfolgt die Zusammenstellung eines Projektportfolios durch 
Auswahl von Einzelprojekten aus einer Liste. Im Folgenden wird dann auf die in der 
relationalen Datenbank gespeicherten Daten der Einzelprojekte in dem Portfolio 
zugegriffen, urn in dem Schritt 302 eine Risikoanalyse fur das Projektportfolio 
insgesamt durchzufuhren. In dem Schritt 304 wird das Analyseergebnis wiederum 
grafisch ausgegeben. 

Die Figur 4 zeigt ein Blockdiagramm eines erfindungsgemaBen Computersy stems. 
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Das Computersystem beinhaltet ein Teilsystem 400 zur Erfassung der Projekt-Daten. 
Hierzu ist ein Modul 402 zur Speicherung von Stammdaten, insbesondere des 
Projektteams vorgesehen. Ein Modul 404 dient zur Speicherung von Dokument- 
vorlagen. Das Modul 406 dient zur Speicherung von Basisdaten zu Projekten in einer 
5 hierarchischen Datenbank. Das Programm 408 dient zur Steuerung des Teilsystems 
400. 

Das Teilsystem 410 greift ebenfalls auf das Modul 402 zur Speicherung von 
Stammdaten zu. Es besitzt ein weiteres Modul (Modul 414) zur Speicherung von 

10 Dokumentenvorlagen fur die Erzeugung der Masterchecklisten und der Bereichs- 
checklisten. Das Modul 416 dient zur Speicherung der Instanzen von Bereichs- 
checklisten und der Masterchecklisten in einer hierarchischen Datenbank. Das 
Programm 418 dient zur Steuerung des Teilsystems 410, sowie zum Export der 
Daten aus der hierarchischen Datenbank in die relationale Datenbank des Teilsystems 

1 5 422 uber die Schnittstelle 420. 

Das Teilsystem 422 fur die Durchfiihrung der Risikoanalyse hat eine relationale 
Datenbank 424, die zur Speicherung der von dem Teilsystem 410 exportierten Daten 
dient. Ferner hat das Teilsystem 422 ein Modul 426" welches ein oder mehrere 
20 vorgegebene Routinen fur Risikoanalysen beinhaltet. Das Modul 428 dient zur 
Ausgabe der Analyseergebnisse. Die Funktion des Teilsystems 422 wird durch das 
Programm 430 gesteuert. 

Das Teilsystem 400 ist femer mit dem Abrechnungsmodul 432 verknupft. Das 
25 Abrechnungsmodul 432 dient fur eine stundengenaue Aufwandserfassung fur die 
Mitarbeiter und fur die Projekte und damit fur das Projektportfolio insgesamt 
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Paten tanspruche 



1. Verfahren zur Risikoanalyse eines Projekts mit folgenden Schritten: 

5 - Erzeugung von Bereichschecklisten in Form von Dokumenten in einer 

hierarchischen Datenbank, wobei die Bereichschecklisten Eingabe- 
felder zur Eingabe von Daten fur die Risikoanalyse aufweisen, 

Export der Daten von der hierarchischen Datenbank in eine relationale 
^0' 1 0 Datenbank, 

Durchfuhrung einer Risikoanalyse fur das Projekt basierend auf den 
Daten, wobei auf die relationale Datenbank zugegriffen wird. 



15 2. Verfahren nach Anspruch 1, wobei die Bereichschecklisten einen initialen 
ersten Status und einen zweiten Status aufweisen, mit folgenden weiteren 
Schritten: 



Erzeugung einer Mastercheckliste fur die Bereichschecklisten in Form 
20 eines Dokuments der hierarchischen Datenbank, wobei die Master- 

checkliste einen initialen ersten Status und einen zweiten Status hat, 

Anderung des initialen ersten Status einer der Bereichschecklisten in 
den zweiten Status, wenn die Daten in die Eingabefelder der einen 
25 Bereichscheckliste eingegeben worden sind, 

Anderung des initialen ersten Status der Mastercheckliste auf den 
zweiten Status, wenn samtliche Bereichschecklisten den zweiten 
Status haben. 



30 
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3. Verfahren nach Anspruch 1 oder 2 3 wobei der Status der Mastercheckliste von 
dem zweiten Status in den ersten Status zuruckgesetzt wird, bevor eine 
Riicksetzung des Status einer der Bereichschecklisten von dem zweiten Status 
in den ersten Status erfolgen kann, urn eine Bearbeitung der Daten in den 
Eingabefeldern dieser Bereichscheckliste vorzunehmen. 

4. Verfahren nach Anspruch 1, 2 oder 3, mit folgenden weiteren Schritten: 

Zugriff auf zumindest erste und zweite Risikoanalyse-Routinen, 

Durchfuhrung von Risikoanalysen nach den zumindest ersten und 
zweiten Risikoanalyse-Routinen, 

grafische Ausgabe der Analyse-Ergebnisse. 

5. Verfahren nach einem der vorhergehenden Anspriiche 1 bis 4, wobei der 
Export der Daten und die Risikoanalyse periodisch oder auf Anforderung hin 
erfolgt. 

6. Verfahren nach einem der vorhergehenden Anspriiche 1 bis 5, mit folgenden 
weiteren Schritten: 

Auswahl eines Projektportfolios, 

Zugriff auf die zu den Projekten des Projektportfolios gehorenden 
Daten in der relationalen Datenbank, 

Durchfuhrung einer Risikoanalyse basierend auf den Daten. 



7. 



Computersystem fur die Risikoanalyse eines Projekts mit: 
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10 



15 



hierarchischen Datenbankmitteln zur Speicherung von Bereichs- 
checklisten in Form von Dokumenten, wobei die Bereichschecklisten 
Eingabefelder zur Eingabe von Daten fur die Risikoanalyse aufweisen, 

relationalen Datenbankmitteln zur Speicherung der zuvor in die 
Eingabefelder der Bereichschecklisten eingegebenen Daten, 

einer Export-Schnittstelle zum Export der Daten von den 
hierarchischen Datenbankmitteln in die relationalen Datenbankmittel, 

ein oder mehrere Risikoanalyse Routinen zur Risikoanalyse des 
Projekts basierend auf den Daten der relationalen Datenbank und zur 
Erzeugung einer grafischen Ausgabe zur Darstellung der Ergebnisse 
der Risikoanalyse. 



8. Computersystem nach Anspruch 7, mit Mitteln zur Erzeugung einer 
Mastercheckliste fur die Bereichschecklisten in Form eines Dokuments der 
hierarchischen Datenbank, wobei die Bereichschecklisten und die 
Mastercheckliste jeweils einen initialen ersten Status und einen zweiten 

20 Status annehmen konnen, wobei der Status der Mastercheckliste auf den 

zweiten Status gesetzt werden kann, nachdem samtliche Bereichschecklisten 
den zweiten Status angenommen haben. 

9. Verfahren nach Anspruch 8, mit Mitteln zum Zurucksetzen des Status der 
25 Mastercheckliste von dem zweiten Status auf den ersten Status, urn eine 

Bearbeitung der Daten in den Eingabefeldern einer Bereichscheckliste zu 
ermoglichen. 



30 



10. Computerprogrammprodukt, insbesondere digitales Speichermedium, 
Diskette, CD-ROM oder Halbleiterspeicher, flir die Risikoanalyse eines 
Projekts mit Programmrnitteln zur bzw. zum: 
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Erzeugung von Bereichschecklisten in Form von Dokumenten in einer 
hierarchischen Datenbank, wobei die Bereichschecklisten 
Eingabefelder zur Eingabe von Daten fur die Risikoanalyse aufweisen, 

5 

Export der Daten von der hierarchischen Datenbank in eine relationale 
Datenbank, 

Durchfuhrung einer Risikoanalyse fur das Projekt basierend auf den 
10 Daten, wobei auf die relationale Datenbank zugegriffen wird. 

11. Computerprogrammprodukt nach Anspruch 10 3 wobei die Programmmittel 
zur periodischen Risikoanalyse oder zur Risikoanalyse auf Anforderung eines 
Benutzers ausgebildet sind. 

15 

12. Computerprogrammprodukt nach Anspruch 10 oder 11, wobei die 
Bereichschecklisten einen initialen ersten Status und einen zweiten Status 
aufweisen, mit folgenden weiteren Schritten: 



20 - Erzeugung einer Mastercheckliste fur die Bereichschecklisten in Form 

s> '^ eines Dokuments der hierarchischen Datenbank, wobei die 

Mastercheckliste einen initialen ersten Status und einen zweiten Status 
hat, 

25 - Anderung des initialen ersten Status einer der Bereichschecklisten in 

den zweiten Status, wenn die Daten in die Eingabefelder der einen 
Bereichscheckliste eingegeben worden sind, 
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Anderung des initialen ersten Status der Mastercheckliste auf den 
zweiten Status, wenn samtliche Bereichschecklisten den zweiten 
Status haben. 
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13. Computerprogrammprodukt nach Anspruch 10, 11 oder 12, wobei der Status 
der Mastercheckliste von dem zweiten Status in den ersten Status 
zuruckgesetzt wird 5 bevor eine Riicksetzung des Status einer der 
Bereichschecklisten von dem zweiten Status in den ersten Status erfolgen 
kann, um eine Bearbeitung der Daten in den Eingabefeldern dieser 
Bereichscheckliste vorzunehmen. 

14. Computerprogrammprodukt nach einem der vorhergehenden Anspruche 10 
bis 13, wobei die Programmmittel ausgebildet sind zum bzw. zur: 

Zugriff auf zumindest erste und zweite Risikoanalyse-Routinen, 

Durchfuhrung von Risikoanalysen nach den zumindest ersten und 
zweiten Risikoanalyse-Routinen, 

grafische Ausgabe der Analyse-Ergebnisse. 
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Verfahren und Computersystem zur Risikoanalyse eines Projekts 

Zusammenfassung 

Die Erfindung betriff ein Verfahren zur Risikoanalyse eines Projekts mit folgenden 
Schritten: 

Erzeugung von Bereichschecklisten in Form von Dokumenten in einer 
hierarchischen Datenbank, wobei die Bereichschecklisten Eingabefelder zur 
Eingabe von Daten fur die Risikoanalyse aufweisen, 

Export der Daten von der hierarchischen Datenbank in eine relationale 
Datenbank, 

Durchfuhrung einer Risikoanalyse fur das Projekt basierend auf den Daten, 
wobei auf die relationale Datenbank zugegriffen wird. 
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